Catala: A Programming Language for the Law

Law at large underpins modern society, codifying and governing many aspects of citizens' daily lives. Oftentimes, law is subject to interpretation, debate and challenges throughout various courts and jurisdictions. But in some other areas, law leaves little room for interpretation, and essentially aims to rigorously describe a computation, a decision procedure or, simply said, an algorithm. Unfortunately, prose remains a woefully inadequate tool for the job. The lack of formalism leaves room for ambiguities; the structure of legal statutes, with many paragraphs and sub-sections spread across multiple pages, makes it hard to compute the intended outcome of the algorithm underlying a given text; and, as with any other piece of poorly-specified critical software, the use of informal language leaves corner cases unaddressed. We introduce Catala, a new programming language that we specifically designed to allow a straightforward and systematic translation of statutory law into an executable implementation. Catala aims to bring together lawyers and programmers through a shared medium, which together they can understand, edit and evolve, bridging a gap that often results in dramatically incorrect implementations of the law. We have implemented a compiler for Catala, and have proven the correctness of its core compilation steps using the F* proof assistant. We evaluate Catala on several legal texts that are algorithms in disguise, notably section 121 of the US federal income tax and the byzantine French family benefits; in doing so, we uncover a bug in the official implementation. We observe as a consequence of the formalization process that using Catala enables rich interactions between lawyers and programmers, leading to a greater understanding of the original legislative intent, while producing a correct-by-construction executable specification reusable by the greater software ecosystem

Unboxed data constructors -- or, how cpp decides a halting problem

We propose a new language feature for ML-family languages, the ability to selectively *unbox* certain data constructors, so that their runtime representation gets compiled away to just the identity on their argument. Unboxing must be statically rejected when it could introduce *confusions*, that is, distinct values with the same representation. We discuss the use-case of big numbers, where unboxing allows to write code that is both efficient and safe, replacing either a safe but slow version or a fast but unsafe version. We explain the static analysis necessary to reject incorrect unboxing requests. We present our prototype implementation of this feature for the OCaml programming language, discuss several design choices and the interaction with advanced features such as Guarded Algebraic Datatypes. Our static analysis requires expanding type definitions in type expressions, which is not necessarily normalizing in presence of recursive type definitions. In other words, we must decide normalization of terms in the first-order lambda-calculus with recursion. We provide an algorithm to detect non-termination on-the-fly during reduction, with proofs of correctness and completeness. Our termination-monitoring algorithm turns out to be closely related to the normalization strategy for macro expansion in the `cpp` preprocessor.Comment: Author version, to appear at POPL 202

Unfolding ML datatype declarations without loops

International audienc

Déboîter les constructeurs

National audienceNous proposons une implémentation d'une nouvelle fonctionnalité pour OCaml, le déboîtement 1 de constructeurs. Elle permet d'éliminer certains constructeurs de la représentation dynamique des valeurs quand cela ne crée pas de confusion entre différentes valeurs au même type. Nous décrivons :-un cas d'usage sur les grands entiers où la fonctionnalité améliore les performances de code OCaml idiomatique,éliminant le besoin d'écrire du code non-sûr.-l'analyse statique nécessaire pour accepter ou rejeter le déboîtement d'un constructeur,-et l'impact sur la compilation du filtrage par motif. Pour notre analyse statique, nous devons normaliser certaines expressions de type, avec une relation de normalisation qui ne termine pas nécessairement en présence de types mutuellement récursifs ; nous décrivons une analyse dynamique de terminaison qui garantit la normalisation sans rejeter les définitions de types qui nous intéressent

Unfolding ML datatype declarations without loops

International audienc

Déboîter les constructeurs

National audienceNous proposons une implémentation d'une nouvelle fonctionnalité pour OCaml, le déboîtement 1 de constructeurs. Elle permet d'éliminer certains constructeurs de la représentation dynamique des valeurs quand cela ne crée pas de confusion entre différentes valeurs au même type. Nous décrivons :-un cas d'usage sur les grands entiers où la fonctionnalité améliore les performances de code OCaml idiomatique,éliminant le besoin d'écrire du code non-sûr.-l'analyse statique nécessaire pour accepter ou rejeter le déboîtement d'un constructeur,-et l'impact sur la compilation du filtrage par motif. Pour notre analyse statique, nous devons normaliser certaines expressions de type, avec une relation de normalisation qui ne termine pas nécessairement en présence de types mutuellement récursifs ; nous décrivons une analyse dynamique de terminaison qui garantit la normalisation sans rejeter les définitions de types qui nous intéressent